home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1192.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  3.7 KB  |  96 lines
  1.  
  2.  
  3. On Mon, 24 May 1993, Tony Sanders wrote:
  4.  
  5. > > 1) Kerberos should normally be invisible to users; there should be a
  6. > > TGT whenever the user is logged in.
  7. > Yes, for a single realm.  The problem is that with the Web you are reading
  8. > documents from all over (many possible realms).  Are you going to require
  9. > that the user kinit in a shell window for each document at a different
  10. > site (possibly having to exit the browser each time for line-mode browsers
  11. > with no job control)?
  12.  
  13.     Well, this is the problem.  The solution is not to use something like
  14. Kerberos to authenticate a user to a publisher, since Kerberos does not scale to
  15. the level we are going to need on the Global Internet.
  16.  
  17.     The easy solution is to support the idea of "authentication servers"
  18. where the user is a member or subscriber to an authentication server which is
  19. responsible to identify the particular user to potential publishers.  The
  20. publisher is a subscriber to the same or a different authentication server (and
  21. in this case, we assume that the authentication servers have a trusted method to
  22. share the burden.)
  23.  
  24.     Let me try a real world example:
  25.  
  26.     aUser subscribes to AuthenticationServer-A.        
  27.             (happens only once)
  28.  
  29.     aUser authenticates herself to AuthenticationServer-A via Kerberos.
  30.             (happens once per session)
  31.  
  32.     aUser is now ready to receive documents.
  33.     -----------------------------------------------------
  34.     aPublisher subscribes to AuthenticationServer-B.
  35.             (happens only once)
  36.  
  37.     aPublisher authenticates itself to AuthenticationServer-B.
  38.             (happens when publisher reboots)
  39.  
  40.     aPublisher is now ready for business.
  41.     -----------------------------------------------------
  42.     aUser wishes to retrieve aDocument from aPublisher
  43.  
  44.     aUser requests aDocument from aPublisher
  45.         -- Along with the request goes something along the lines of:
  46.             AuthAgency    AuthMethod    UserCredentials
  47.             ----------    ----------    ---------------
  48.             Server-A    Kerberos        [HOSTNAME] 
  49.                             [USERNAME] 
  50.                             [KERB-TICKET]  (opaque data)
  51.  
  52.             a URA (Uniform Resource Authenticator) might look like:
  53.             Kerberos://Server-A/hostname/username/kerb-ticket
  54.  
  55.     aPublisher checks with AuthenticationServer-B for aUser's credentials
  56.  
  57.     AuthenticationServer-B does not recognize aUser
  58.  
  59.     AuthenticationServer-B contacts AuthenticationServer-A and requests
  60.     credentials for aUser
  61.  
  62.     AuthenticationServer-A returns the proper credentials and...
  63.  
  64.     well, you get the picture....
  65.  
  66.  
  67.     The idea here is that Kerberos by itself is not an authentication
  68. service.  It is a mechanism which can be used to develop such a service.
  69.  
  70.     I would assume that all the AuthenticationServers might use Kerberos to
  71. share info between them, and that all the Users might use Kerberos to
  72. authenticate themselves to the AuthenticationServers.  Of course, there is room
  73. for more and less robust mechanisms as well, depending on the publisher's needs.
  74.  
  75.     There needs to be a major infrastructure of authenticating and authorizing
  76. capabilities on the Internet to support "publishing."  It is not simply a
  77. question of client/server (consumer/producer) because the model does not scale.
  78.  
  79. > > 3) It's bad policy for users to get into the habit of entering their
  80. > > passwords into programs other than passwd, kinit and login.
  81. > I cannot think of any other reasonable solution with the current
  82. > technology (and I'm not interested in rolling my own).
  83.  
  84.     Ahhhh... but I am.  <smile>  O'Reilly is hoping to take a lead here, and
  85. we are actively developing an document which outlines the problems and proposes
  86. a solution.  We are also developing a testbed application, and will ultimately
  87. make this available to other publishers and the network at large.
  88.  
  89.     Anyone interested in particpating, (at this point, in a discussion, but
  90. perhaps in the beta-release), should drop me a line.
  91.  
  92.     </rr>
  93.  
  94.  
  95.  
  96.